The Policy and Charging Control (PCC) architecture is illustrated in FIG. 1 and disclosed in 3GPP TS 23.203 V13.4.0 that specifies the PCC functionality for Evolved 3GPP Packet Switched domain, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. For the purpose of the present invention, the PCC architecture includes a Policy and Charging Rules Function (PCRF), a Policy and Charging Enforcement Function (PCEF), a Traffic Detection Function (TDF), a Subscription Profile Repository (SPR) and an Online Charging System (OCS) to allow charging decisions.
The PCRF is in charge of policy control decision and flow based charging control, and provides network control for service data flow detection, gating, quality of service (QoS) and flow based charging towards the PCEF by holding policies and providing PCC rules to the PCEF per service data flow basis for enforcement of such policies.
The PCEF encompasses service data flow detection, policy enforcement and flow based charging functionalities by enforcing the PCC rules received from the PCRF. Deep Packet Inspection (DPI) technology, embedded in PCEF, supports packet inspection and service classification, which consists on IP packets classified according to a configured tree of rules so that they are assigned to a particular service session.
The TDF, as specified in 3GPP TR 23.813 V11.0.0, is in charge of performing application's traffic detection and reporting of the detected application to the PCRF, it supports packet inspection and service classification, in accordance with Application Detection and Control (ADC) rules received from the PCRF, and can be either stand-alone or collocated with the PCEF. Where the PCEF includes the TDF, it may also be referred to as a PCEF with deep packet inspection (DPI) capabilities, and the PCC rules include the ADC rules.
This PCC architecture may also include a Bearer Binding and Event Reporting Function (BBERF) which, for the purpose of the present invention, behaves in a similar manner and for a similar purpose as the PCEF, but for receiving and handling Quality of Service (QoS) rules instead of PCC rules. The PCC architecture may also include an Application Function (AF) which is an element offering applications that require dynamic policy and/or charging control over the IP Connectivity Access Network (IP-CAN) user plane behaviour. The AF communicates with the PCRF through an Rx reference point to transfer dynamic session information, required for PCRF decisions as well as to receive IP-CAN specific information and notifications about IP-CAN bearer level events.
3GPP TS 29.212 V13.2.0 specifies the operations on PCC rules, ADC rules and QoS rules, as well as the particular parameters that a PCC rule, an ADC rule and a QoS rule may comprise. The PCC rules, ADC rules and QoS rules may be dynamic rules provisioned by the PCRF, or static rules respectively predefined at the PCEF, TDF and BBERF. The operations available for dynamic rules are: installation, modification and removal; whereas the operations available for static rules are: activation and deactivation.
A PCC rule and a QoS rule include a service data flow filter used to identify a service data flow, and one or more service data flow filters are used to select the traffic for which the PCC rule and the QoS rule applies. An ADC rule includes a TDF application identifier used to reference the corresponding application, for which the ADC rule applies. The same application identifier value can occur in more than one ADC rule and, if so, the PCRF ensures that there is at most one ADC rule active per application identifier value at any time.
The SPR is in charge of providing subscription data for a user to the PCRF and contains all subscription-related information needed for subscription-based policies. Apart from that, a User Data Repository (UDR), as disclosed in 3GPP TS 23.335 V12.0.0, may replace the SPR for provision of subscription data to the PCRF.
3GPP TS 23.203 discloses a Gx reference point (interface) between the PCRF and the PCEF, an Sd reference point between the PCRF and the stand-alone TDF, an Sp reference point between the PCRF and the SPR, a Gxx reference point between the PCRF and the BBERF, an Ud reference point between the PCRF and the UDR, and a Gy reference point between the PCEF and the OCS.
In particular, the PCEF may be located at e.g. a gateway GPRS support node (GGSN) in a general packet radio service (GPRS) core network. The GPRS core network allows 2G, 3G and WCDMA mobile networks to transmit IP packets to external networks such as the Internet. For the cases where there is a Proxy Mobile IP (PMIP) protocol instead of a GPRS tunnelling protocol (GTP) between a Bearer Binding and Event Reporting Function (BBERF) and the PCEF, the bearer control is done in the BBERF instead. Moreover, the PCEF may also be located at e.g. a packet data network gateway (PGW) in an evolved packet system (EPS) network. The PGW, which may also be abbreviated as PDN GW, is the point of interconnect between the evolved packet core (EPC) and the external IP networks. Furthermore, the PCEF may also be located at e.g. a packet data gateway (PDG) for connecting an untrusted WLAN network with a 3GPP network. In this scenario, the PDG may be a gateway to a specific packet data network, such as the internet or an operator service network.
At present, a Sponsor (e.g. an Application Service Provider, ASP) is an entity taking the operator's charge for connectivity. That is, the Sponsor can pay for user's data usage in order to allow the user to access sponsored services implemented on one or more Sponsor nodes, e.g. an ASP service implemented on an ASP node, of a telecommunication network. A Sponsor node may be co-located on a same platform as other nodes, e.g. servers and devices, mentioned throughout this specification, or separately. For the sake of simplicity, the Sponsor node may simply be referred in the following as the Sponsor. This enables additional revenue opportunities for both the ASPs and the operators. In particular, a dynamic data usage provided by the Sponsor allows the operator to increase revenues from the users with limited data plans. The user may have limited data plans allowing only a nominal data volume per month and the Sponsor may dynamically sponsor additional volume for the user to allow access to the sponsored services offered by the ASPs. In this respect, 3GPP TR 23.813 specifies Sponsored Data Connectivity for basic sponsoring use cases through Rx and Gx reference points.
The PCC architecture can be enhanced to enable such use cases. In particular, the PCC architecture allows the operator to provide service control based on such sponsored services. For example, it allows a dynamic IP flow to be excluded from the user's data plan since a Sponsor might sponsor the data usage for the identified IP flows. For example, the user may use the limited data plan to browse an online store for interesting books; but once a book is purchased, the data usage for downloading the book can be granted for free. In addition, the IP flow may also be granted certain level of QoS (e.g. video streaming). Currently, as specified in 3GPP TR 23.813, sponsored data connectivity is notified from an AF of the PCC architecture to the PCRF. The AF is connected with the ASP, which sponsors the data connectivity, and with the PCRF via the Rx reference point. In operation, once the user accesses the ASP node to run the sponsored service, the ASP triggers towards the AF the required data connectivity to sponsor the sponsored service, and the AF submits to the PCRF the sponsored data connectivity for the sponsored service. The PCRF only needs to know the required information to identify the service and to describe the sponsored IP flows towards the PCEF with derived PCC rules.
Even though current solutions allow users to get and use sponsored services, the users cannot previously know which the sponsored services are and, if a user ignores the existence of a sponsored service, such user would instead use a subscribed service subject to a subscribed quota, e.g. a quoted service subject to charging by the user's operator. In other words, the users should be aware of the sponsored services before being able to use them.